createProject writes project:{id} before adding it to the projectIds
index, and rolls the record back if the index write fails. If that
rollback delete also fails, the record was orphaned forever — never
listed, never deleted, pure storage bloat.

The PAPI storage API exposes only read/write/delete with no key
enumeration, so reconciling live keys against the index isn't possible.
Instead, record the orphaned id in a persistent pendingCleanup set on
rollback failure, and retry the deletion opportunistically on the next
activation via a fire-and-forget sweep.

- Add pendingCleanup storage key with its own serialization queue so
  recording an orphan and sweeping can't clobber each other's writes.
- recordPendingCleanup: idempotently add an orphan id; a failure to
  record is logged and swallowed so it never masks the original index
  error the caller must see.
- sweepPendingCleanup: retry each recorded delete (ENOENT = already
  gone = success), clear cleaned ids, retain ids that fail again.
- Run the sweep at activation, fire-and-forget: a cleanup failure never
  blocks activation and it retries on the next run.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

A corrupt pendingCleanup value was recovered as empty but the sweep's
empty-set early return skipped the rewrite, so the bad value survived
and
re-warned on every launch. Report corruption from readPendingCleanup and
overwrite the key with [] when nothing is left to sweep.